-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature-gate #[must_use] for functions as fn_must_use
#43776
Conversation
// gate-test-fn_must_use | ||
|
||
#[must_use] | ||
fn use_it() -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test is written wrongly, it should add an //~ ERROR #[must_use] on function is experimental
to one of these two lines (depends on which span is used to report the error).
// option. This file may not be copied, modified, or distributed | ||
// except according to those terms. | ||
|
||
// gate-test-fn_must_use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tidy error: /checkout/src/test/compile-fail/feature-gate-fn_must_use.rs:11: The file is already marked as gate test through its name, no need for a 'gate-test-fn_must_use' comment
☔ The latest upstream changes (presumably #43522) made this pull request unmergeable. Please resolve the merge conflicts. |
It's a breaking change -- Rust 1.19 thinks |
r? @rust-lang/libs |
The behavior as of the current revision of this pull request (Travis is currently failing because of tidy and the feature-gate test, but we can fix that after we understand what we want) would be the same with respect to allowing
@kennytm Are we allowed to make it a warning rather than a hard error? (To avoid it being a breaking change, see @bluss's comment.) |
A future-incompatible warning like E0122 can be issued. But that's up to the lang team to decide.
|
Thanks for the PR @zackmdavis! I think @kennytm's suggestions are all that's needed to land this! |
bad6afc
to
a937dca
Compare
(Updated—includes reworking some feature-gate functionality to be able to only emit a warning. On the other hand, if we decide we want a hard error (is there really going to be much code in the wild that has a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I wonder if it would be possible to gate as a "hard" error by default? That may help reduce the surrounding changes here!
// below (which makes this compile-fail test fail) doesn't have anything to | ||
// do with the feature-gating, but pragmatically if awkwardly solves this | ||
// dilemma until a superior solution can be devised. | ||
== //~ ERROR expected expression |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also have #[rustc_error]
used throughout the test suite which may help here?
a937dca
to
398f414
Compare
Fine with me (pull request updated). A compatibility bullet point in the release notes seems appropriate, though. |
Oh oops sorry! I think I miscommunicated a bit. I think it's probably a good idea to avoid turning I wonder if perhaps though there's a more targeted way of "deprecating" the |
398f414
to
0f385f4
Compare
Oh, right. I did do some defaulting for the macros (which can be variadic), but I was trying to avoid too much code duplication. Looking at it today, I'm sure a much better trade-off between avoiding duplication and avoiding polluting existing |
Yeah the behavior of the current patch is fine by me, thanks! I'd just recommend a littl erefactoring to avoid needing to pass |
We'll actually want a new "soft" warning-only gate to maintain backwards-compatibility, but it's cleaner to start out with the established, well-understood gate before implementing the alternative warn-only behavior in a later commit. This is in the matter of rust-lang#43302.
The featureck.py that this comment referred to was removed in 9dd3c54 (March 2016).
8f6724b
to
6ca5490
Compare
Before `#[must_use]` for functions was implemented, a `#[must_use]` attribute on a function was a no-op. To avoid a breaking change in this behavior, we add an option for "this-and-such feature is experimental" feature-gate messages to be a mere warning rather than a compilation-halting failure (so old code that used to have a useless no-op `#[must_use]` attribute now warns rather than breaking). When we're on stable, we add a help note to clarify that the feature isn't "on." This is in support of rust-lang#43302.
This continues to be in the matter of rust-lang#43302.
6ca5490
to
35c4494
Compare
@alexcrichton updated (the only Travis subjobs that haven't passed yet are all macOS stuff) |
@bors: r+ |
📌 Commit 35c4494 has been approved by |
⌛ Testing commit 35c4494 with merge 1e20ae244f66a819647a597712fee38706ca1356... |
😪 I'm awake I'm awake |
@bors retry |
⌛ Testing commit 35c4494 with merge abd03494a40b02d6fa04f4cd1d025bb04423c61c... |
💔 Test failed - status-appveyor |
@bors retry rollup
|
…, r=alexcrichton feature-gate #[must_use] for functions as `fn_must_use` @eddyb I [was](rust-lang#43728 (comment)) [dithering](rust-lang#43728 (comment)) on this, but [your comment](rust-lang#43302 (comment)) makes it sound like we do want a feature gate for this? Please advise. r? @eddyb
I think this should be reverted: #44213 (comment) |
@eddyb I was dithering on this, but your comment makes it sound like we do want a feature gate for this? Please advise.
r? @eddyb